Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stabilize raw_ref_op (RFC 2582) #127679

Merged
merged 3 commits into from
Aug 19, 2024
Merged

Stabilize raw_ref_op (RFC 2582) #127679

merged 3 commits into from
Aug 19, 2024

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Jul 13, 2024

This stabilizes the syntax &raw const $expr and &raw mut $expr. It has existed unstably for ~4 years now, and has been exposed on stable via the addr_of and addr_of_mut macros since Rust 1.51 (released more than 3 years ago). I think it has become clear that these operations are here to stay. So it is about time we give them proper primitive syntax. This has two advantages over the macro:

  • Being macros, addr_of/addr_of_mut could in theory do arbitrary magic with the expression on which they work. The only "magic" they actually do is using the argument as a place expression rather than as a value expression. Place expressions are already a subtle topic and poorly understood by many programmers; having this hidden behind a macro using unstable language features makes this even worse. Conversely, people do have an idea of what happens below &/&mut, so we can make the subtle topic a lot more approachable by connecting to existing intuition.
  • The name addr_of is quite unfortunate from today's perspective, given that we have accepted provenance as a reality, which means that a pointer is not just an address. Strict provenance has a method, addr, which extracts the address of a pointer; using the term addr in two different ways is quite unfortunate. That's why this PR soft-deprecates addr_of -- we will wait a long time before actually showing any warning here, but we should start telling people that the "addr" part of this name is somewhat misleading, and &raw avoids that potential confusion.

In summary, this syntax improves developers' ability to conceptualize the operational semantics of Rust, while making a fundamental operation frequently used in unsafe code feel properly built in.

Possible questions to consider, based on the RFC and this great summary by @CAD97:

  • Some questions are entirely about the semantics. The semantics are the same as with the macros so I don't think this should have any impact on this syntax PR. Still, for completeness' sake:
  • Choose a different syntax? I don't want to re-litigate the RFC. The only credible alternative that has been proposed is &raw $place instead of &raw const $place, which (IIUC) could be achieved by making raw a contextual keyword in a new edition. The type is named *const T, so the explicit const is consistent in that regard. &raw expr lacks the explicit indication of immutability. However, &raw const expr is quite a but longer than addr_of!(expr).
  • Shouldn't we have a completely new, better raw pointer type instead? Yes we all want to see that happen -- but I don't think we should block stabilization on that, given that such a nicer type is not on the horizon currently and given the issues with addr_of! mentioned above. (If we keep the &raw $place syntax free for this, we could use it in the future for that new type.)
  • What about the lint the RFC talked about? It hasn't been implemented yet. Given that the problematic code is UB with or without this stabilization, I don't think the lack of the lint should block stabilization.
  • Other points from the "future possibilites of the RFC
    • "Syntactic sugar" extension: this has not been implemented. I'd argue this is too confusing, we should stick to what the RFC suggested and if we want to do anything about such expressions, add the lint.
    • Encouraging / requiring &raw in situations where references are often/definitely incorrect: this has been / is being implemented. On packed fields this already is a hard error, and for static mut a lint suggesting raw pointers is being rolled out.
    • Lowering of casts: this has been implemented. (It's also an invisible implementation detail.)
    • offsetof woes: we now have native offset_of so this is not relevant any more.

To be done before landing:

Fixes #64490

cc @rust-lang/lang @rust-lang/opsem

try-job: x86_64-msvc
try-job: test-various
try-job: dist-various-1
try-job: armhf-gnu
try-job: aarch64-apple

@rustbot
Copy link
Collaborator

rustbot commented Jul 13, 2024

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot

This comment was marked as resolved.

@rustbot rustbot added PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 13, 2024
@rustbot
Copy link
Collaborator

rustbot commented Jul 13, 2024

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in src/tools/cargo

cc @ehuss

Some changes occurred in tests/ui/sanitizer

cc @rust-lang/project-exploit-mitigations, @rcvalle

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

@RalfJung RalfJung added T-lang Relevant to the language team, which will review and decide on the PR/issue. I-lang-nominated Nominated for discussion during a lang team meeting. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. PG-exploit-mitigations Project group: Exploit mitigations labels Jul 13, 2024
@RalfJung
Copy link
Member Author

@rust-lang/lang nominating for discussion. See the PR description for a summary of all relevant details. :)

Cc @rust-lang/opsem

@RalfJung RalfJung added the relnotes Marks issues that should be documented in the release notes of the next release. label Jul 13, 2024
@rust-log-analyzer

This comment has been minimized.

@rustbot rustbot added the PG-exploit-mitigations Project group: Exploit mitigations label Jul 13, 2024
@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the raw_ref_op branch 2 times, most recently from a16b5eb to 069b996 Compare July 14, 2024 06:13
@traviscross traviscross changed the title stabilize raw_ref_op Stabilize raw_ref_op Jul 15, 2024
@traviscross traviscross changed the title Stabilize raw_ref_op Stabilize raw_ref_op (RFC 2582) Jul 15, 2024
@nikomatsakis
Copy link
Contributor

nikomatsakis commented Jul 15, 2024 via email

@saethlin
Copy link
Member

saethlin commented Jul 15, 2024

I think for me the bigger challenge is that I'm still not 100% clear on the "mental model" for validity requirements of references vs raw pointers.

How is that related to this stabilization? I follow the rest of your comment, but not this last bit.

@RalfJung
Copy link
Member Author

@nikomatsakis what about the two first points in the PR, the arguments in favor of stabilizing this?

I am happy to elaborate on the raw pointer op.sem and what is and is not UB, if you have any specific questions.

@joshtriplett
Copy link
Member

I'm going to go ahead and propose FCP, to asynchronously see how close we are to consensus. (This does not preclude the filing of concerns.)

@rfcbot merge

@rfcbot
Copy link

rfcbot commented Jul 22, 2024

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

Concerns:

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Jul 22, 2024
@bors
Copy link
Contributor

bors commented Aug 18, 2024

📌 Commit 35709be has been approved by jieyouxu

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 18, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 19, 2024
Rollup of 7 pull requests

Successful merges:

 - rust-lang#127679 (Stabilize `raw_ref_op` (RFC 2582))
 - rust-lang#128084 (Suggest adding Result return type for associated method in E0277.)
 - rust-lang#128628 (When deduplicating unreachable blocks, erase the source information.)
 - rust-lang#128902 (doc: std::env::var: Returns None for names with '=' or NUL byte)
 - rust-lang#129048 (Update `crosstool-ng` for loongarch64)
 - rust-lang#129116 (Include a copy of `compiler-rt` source in the `download-ci-llvm` tarball)
 - rust-lang#129208 (Fix order of normalization and recursion in const folding.)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit f27a9b1 into rust-lang:master Aug 19, 2024
6 checks passed
@rustbot rustbot added this to the 1.82.0 milestone Aug 19, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Aug 19, 2024
Rollup merge of rust-lang#127679 - RalfJung:raw_ref_op, r=jieyouxu

Stabilize `raw_ref_op` (RFC 2582)

This stabilizes the syntax `&raw const $expr` and `&raw mut $expr`. It has existed unstably for ~4 years now, and has been exposed on stable via the `addr_of` and `addr_of_mut` macros since Rust 1.51 (released more than 3 years ago). I think it has become clear that these operations are here to stay. So it is about time we give them proper primitive syntax. This has two advantages over the macro:

- Being macros, `addr_of`/`addr_of_mut` could in theory do arbitrary magic with the expression on which they work. The only "magic" they actually do is using the argument as a place expression rather than as a value expression. Place expressions are already a subtle topic and poorly understood by many programmers; having this hidden behind a macro using unstable language features makes this even worse. Conversely, people do have an idea of what happens below `&`/`&mut`, so we can make the subtle topic a lot more approachable by connecting to existing intuition.
- The name `addr_of` is quite unfortunate from today's perspective, given that we have accepted provenance as a reality, which means that a pointer is *not* just an address. Strict provenance has a method, `addr`, which extracts the address of a pointer; using the term `addr` in two different ways is quite unfortunate. That's why this PR soft-deprecates `addr_of` -- we will wait a long time before actually showing any warning here, but we should start telling people that the "addr" part of this name is somewhat misleading, and `&raw` avoids that potential confusion.

In summary, this syntax improves developers' ability to conceptualize the operational semantics of Rust, while making a fundamental operation frequently used in unsafe code feel properly built in.

Possible questions to consider, based on the RFC and [this](rust-lang#64490 (comment)) great summary by `@CAD97:`

- Some questions are entirely about the semantics. The semantics are the same as with the macros so I don't think this should have any impact on this syntax PR. Still, for completeness' sake:
  - Should `&raw const *mut_ref` give a read-only pointer?
    - Tracked at: rust-lang/unsafe-code-guidelines#257
    - I think ideally the answer is "no". Stacked Borrows says that pointer is read-only, but Tree Borrows says it is mutable.
  - What exactly does `&raw const (*ptr).field` require? Answered in [the reference](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html): the arithmetic to compute the field offset follows the rules of `ptr::offset`, making it UB if it goes out-of-bounds. Making this a safe operation (using `wrapping_offset` rules) is considered too much of a loss for alias analysis.
- Choose a different syntax? I don't want to re-litigate the RFC. The only credible alternative that has been proposed is `&raw $place` instead of `&raw const $place`, which (IIUC) could be achieved by making `raw` a contextual keyword in a new edition. The type is named `*const T`, so the explicit `const` is consistent in that regard. `&raw expr` lacks the explicit indication of immutability. However, `&raw const expr` is quite a but longer than `addr_of!(expr)`.
- Shouldn't we have a completely new, better raw pointer type instead? Yes we all want to see that happen -- but I don't think we should block stabilization on that, given that such a nicer type is not on the horizon currently and given the issues with `addr_of!` mentioned above. (If we keep the `&raw $place` syntax free for this, we could use it in the future for that new type.)
- What about the lint the RFC talked about? It hasn't been implemented yet.  Given that the problematic code is UB with or without this stabilization, I don't think the lack of the lint should block stabilization.
  - I created an issue to track adding it: rust-lang#127724
- Other points from the "future possibilites of the RFC
  - "Syntactic sugar" extension: this has not been implemented. I'd argue this is too confusing, we should stick to what the RFC suggested and if we want to do anything about such expressions, add the lint.
  - Encouraging / requiring `&raw` in situations where references are often/definitely incorrect: this has been / is being implemented. On packed fields this already is a hard error, and for `static mut` a lint suggesting raw pointers is being rolled out.
  - Lowering of casts: this has been implemented. (It's also an invisible implementation detail.)
  - `offsetof` woes: we now have native `offset_of` so this is not relevant any more.

To be done before landing:

- [x] Suppress `unused_parens` lint around `&raw {const|mut}` expressions
  - See bottom of rust-lang#127679 (comment) for rationale
  - Implementation: rust-lang#128782
- [ ] Update the Reference.
  - rust-lang/reference#1567

Fixes rust-lang#64490

cc `@rust-lang/lang` `@rust-lang/opsem`

try-job: x86_64-msvc
try-job: test-various
try-job: dist-various-1
try-job: armhf-gnu
try-job: aarch64-apple
@RalfJung RalfJung deleted the raw_ref_op branch August 19, 2024 11:33
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Aug 20, 2024
Stabilize `raw_ref_op` (RFC 2582)

This stabilizes the syntax `&raw const $expr` and `&raw mut $expr`. It has existed unstably for ~4 years now, and has been exposed on stable via the `addr_of` and `addr_of_mut` macros since Rust 1.51 (released more than 3 years ago). I think it has become clear that these operations are here to stay. So it is about time we give them proper primitive syntax. This has two advantages over the macro:

- Being macros, `addr_of`/`addr_of_mut` could in theory do arbitrary magic with the expression on which they work. The only "magic" they actually do is using the argument as a place expression rather than as a value expression. Place expressions are already a subtle topic and poorly understood by many programmers; having this hidden behind a macro using unstable language features makes this even worse. Conversely, people do have an idea of what happens below `&`/`&mut`, so we can make the subtle topic a lot more approachable by connecting to existing intuition.
- The name `addr_of` is quite unfortunate from today's perspective, given that we have accepted provenance as a reality, which means that a pointer is *not* just an address. Strict provenance has a method, `addr`, which extracts the address of a pointer; using the term `addr` in two different ways is quite unfortunate. That's why this PR soft-deprecates `addr_of` -- we will wait a long time before actually showing any warning here, but we should start telling people that the "addr" part of this name is somewhat misleading, and `&raw` avoids that potential confusion.

In summary, this syntax improves developers' ability to conceptualize the operational semantics of Rust, while making a fundamental operation frequently used in unsafe code feel properly built in.

Possible questions to consider, based on the RFC and [this](rust-lang/rust#64490 (comment)) great summary by `@CAD97:`

- Some questions are entirely about the semantics. The semantics are the same as with the macros so I don't think this should have any impact on this syntax PR. Still, for completeness' sake:
  - Should `&raw const *mut_ref` give a read-only pointer?
    - Tracked at: rust-lang/unsafe-code-guidelines#257
    - I think ideally the answer is "no". Stacked Borrows says that pointer is read-only, but Tree Borrows says it is mutable.
  - What exactly does `&raw const (*ptr).field` require? Answered in [the reference](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html): the arithmetic to compute the field offset follows the rules of `ptr::offset`, making it UB if it goes out-of-bounds. Making this a safe operation (using `wrapping_offset` rules) is considered too much of a loss for alias analysis.
- Choose a different syntax? I don't want to re-litigate the RFC. The only credible alternative that has been proposed is `&raw $place` instead of `&raw const $place`, which (IIUC) could be achieved by making `raw` a contextual keyword in a new edition. The type is named `*const T`, so the explicit `const` is consistent in that regard. `&raw expr` lacks the explicit indication of immutability. However, `&raw const expr` is quite a but longer than `addr_of!(expr)`.
- Shouldn't we have a completely new, better raw pointer type instead? Yes we all want to see that happen -- but I don't think we should block stabilization on that, given that such a nicer type is not on the horizon currently and given the issues with `addr_of!` mentioned above. (If we keep the `&raw $place` syntax free for this, we could use it in the future for that new type.)
- What about the lint the RFC talked about? It hasn't been implemented yet.  Given that the problematic code is UB with or without this stabilization, I don't think the lack of the lint should block stabilization.
  - I created an issue to track adding it: rust-lang/rust#127724
- Other points from the "future possibilites of the RFC
  - "Syntactic sugar" extension: this has not been implemented. I'd argue this is too confusing, we should stick to what the RFC suggested and if we want to do anything about such expressions, add the lint.
  - Encouraging / requiring `&raw` in situations where references are often/definitely incorrect: this has been / is being implemented. On packed fields this already is a hard error, and for `static mut` a lint suggesting raw pointers is being rolled out.
  - Lowering of casts: this has been implemented. (It's also an invisible implementation detail.)
  - `offsetof` woes: we now have native `offset_of` so this is not relevant any more.

To be done before landing:

- [x] Suppress `unused_parens` lint around `&raw {const|mut}` expressions
  - See bottom of rust-lang/rust#127679 (comment) for rationale
  - Implementation: rust-lang/rust#128782
- [ ] Update the Reference.
  - rust-lang/reference#1567

Fixes rust-lang/rust#64490

cc `@rust-lang/lang` `@rust-lang/opsem`

try-job: x86_64-msvc
try-job: test-various
try-job: dist-various-1
try-job: armhf-gnu
try-job: aarch64-apple
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Aug 22, 2024
@Mark-Simulacrum Mark-Simulacrum added relnotes Marks issues that should be documented in the release notes of the next release. and removed relnotes Marks issues that should be documented in the release notes of the next release. labels Aug 25, 2024
github-merge-queue bot pushed a commit to model-checking/kani that referenced this pull request Aug 28, 2024
Upgrades toolchain to 08/28

Culprit upstream changes:
1. rust-lang/rust#128812
2. rust-lang/rust#128703
3. rust-lang/rust#127679
4. rust-lang/rust-clippy#12993
5. rust-lang/cargo#14370
6. rust-lang/rust#128806

Resolves #3429
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 and MIT licenses.
cuviper added a commit to cuviper/rust that referenced this pull request Sep 26, 2024
Since the stabilization in rust-lang#127679 has reached stage0, 1.82-beta, we can
start using `&raw` freely, and even the soft-deprecated `ptr::addr_of!`
and `ptr::addr_of_mut!` can stop allowing the unstable feature.

I intentionally did not change any documentation or tests, but the rest
of those macro uses are all now using `&raw const` or `&raw mut` in the
standard library.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Sep 26, 2024
…ss35

Use `&raw` in the standard library

Since the stabilization in rust-lang#127679 has reached stage0, 1.82-beta, we can
start using `&raw` freely, and even the soft-deprecated `ptr::addr_of!`
and `ptr::addr_of_mut!` can stop allowing the unstable feature.

I intentionally did not change any documentation or tests, but the rest
of those macro uses are all now using `&raw const` or `&raw mut` in the
standard library.
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 26, 2024
Use `&raw` in the standard library

Since the stabilization in rust-lang#127679 has reached stage0, 1.82-beta, we can
start using `&raw` freely, and even the soft-deprecated `ptr::addr_of!`
and `ptr::addr_of_mut!` can stop allowing the unstable feature.

I intentionally did not change any documentation or tests, but the rest
of those macro uses are all now using `&raw const` or `&raw mut` in the
standard library.
tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request Oct 18, 2024
This MR contains the following updates:

| Package | Update | Change |
|---|---|---|
| [rust](https://github.com/rust-lang/rust) | minor | `1.81.0` -> `1.82.0` |

MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot).

**Proposed changes to behavior should be submitted there as MRs.**

---

### Release Notes

<details>
<summary>rust-lang/rust (rust)</summary>

### [`v1.82.0`](https://github.com/rust-lang/rust/blob/HEAD/RELEASES.md#Version-1820-2024-10-17)

[Compare Source](rust-lang/rust@1.81.0...1.82.0)

\==========================

<a id="1.82.0-Language"></a>

## Language

-   [Don't make statement nonterminals match pattern nonterminals](rust-lang/rust#120221)
-   [Patterns matching empty types can now be omitted in common cases](rust-lang/rust#122792)
-   [Enforce supertrait outlives obligations when using trait impls](rust-lang/rust#124336)
-   [`addr_of(_mut)!` macros and the newly stabilized `&raw (const|mut)` are now safe to use with all static items](rust-lang/rust#125834)
-   [size_of_val_raw: for length 0 this is safe to call](rust-lang/rust#126152)
-   [Reorder trait bound modifiers *after* `for<...>` binder in trait bounds](rust-lang/rust#127054)
-   [Stabilize opaque type precise capturing (RFC 3617)](rust-lang/rust#127672)
-   [Stabilize `&raw const` and `&raw mut` operators (RFC 2582)](rust-lang/rust#127679)
-   [Stabilize unsafe extern blocks (RFC 3484)](rust-lang/rust#127921)
-   [Stabilize nested field access in `offset_of!`](rust-lang/rust#128284)
-   [Do not require `T` to be live when dropping `[T; 0]`](rust-lang/rust#128438)
-   [Stabilize `const` operands in inline assembly](rust-lang/rust#128570)
-   [Stabilize floating-point arithmetic in `const fn`](rust-lang/rust#128596)
-   [Stabilize explicit opt-in to unsafe attributes](rust-lang/rust#128771)
-   [Document NaN bit patterns guarantees](rust-lang/rust#129559)

<a id="1.82.0-Compiler"></a>

## Compiler

-   [Promote riscv64gc-unknown-linux-musl to tier 2](rust-lang/rust#122049)
-   [Promote Mac Catalyst targets `aarch64-apple-ios-macabi` and `x86_64-apple-ios-macabi` to Tier 2, and ship them with rustup](rust-lang/rust#126450)
-   [Add tier 3 NuttX based targets for RISC-V and ARM](rust-lang/rust#127755)
-   [Add tier 3 powerpc-unknown-linux-muslspe target](rust-lang/rust#127905)
-   [Improved diagnostics to explain why a pattern is unreachable](rust-lang/rust#128034)
-   [The compiler now triggers the unreachable code warning properly for async functions that don't return/are `-> !`](rust-lang/rust#128443)
-   [Promote `aarch64-apple-darwin` to Tier 1](rust-lang/rust#128592)
-   [Add Trusty OS target `aarch64-unknown-trusty` and `armv7-unknown-trusty` as tier 3 targets](rust-lang/rust#129490)
-   [Promote `wasm32-wasip2` to Tier 2.](rust-lang/rust#126967)

<a id="1.82.0-Libraries"></a>

## Libraries

-   [Generalize `{Rc,Arc}::make_mut()` to `Path`, `OsStr`, and `CStr`.](rust-lang/rust#126877)

<a id="1.82.0-Stabilized-APIs"></a>

## Stabilized APIs

-   [`std::thread::Builder::spawn_unchecked`](https://doc.rust-lang.org/stable/std/thread/struct.Builder.html#method.spawn_unchecked)
-   [`std::str::CharIndices::offset`](https://doc.rust-lang.org/nightly/std/str/struct.CharIndices.html#method.offset)
-   [`std::option::Option::is_none_or`](https://doc.rust-lang.org/nightly/std/option/enum.Option.html#method.is_none_or)
-   [`[T]::is_sorted`](https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.is_sorted)
-   [`[T]::is_sorted_by`](https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.is_sorted_by)
-   [`[T]::is_sorted_by_key`](https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.is_sorted_by_key)
-   [`Iterator::is_sorted`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.is_sorted)
-   [`Iterator::is_sorted_by`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.is_sorted_by)
-   [`Iterator::is_sorted_by_key`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.is_sorted_by_key)
-   [`std::future::Ready::into_inner`](https://doc.rust-lang.org/nightly/std/future/struct.Ready.html#method.into_inner)
-   [`std::iter::repeat_n`](https://doc.rust-lang.org/nightly/std/iter/fn.repeat_n.html)
-   [`impl<T: Clone> DoubleEndedIterator for Take<Repeat<T>>`](https://doc.rust-lang.org/nightly/std/iter/struct.Take.html#impl-DoubleEndedIterator-for-Take%3CRepeat%3CT%3E%3E)
-   [`impl<T: Clone> ExactSizeIterator for Take<Repeat<T>>`](https://doc.rust-lang.org/nightly/std/iter/struct.Take.html#impl-ExactSizeIterator-for-Take%3CRepeat%3CT%3E%3E)
-   [`impl<T: Clone> ExactSizeIterator for Take<RepeatWith<T>>`](https://doc.rust-lang.org/nightly/std/iter/struct.Take.html#impl-ExactSizeIterator-for-Take%3CRepeatWith%3CF%3E%3E)
-   [`impl Default for std::collections::binary_heap::Iter`](https://doc.rust-lang.org/nightly/std/collections/binary_heap/struct.Iter.html#impl-Default-for-Iter%3C'\_,+T%3E)
-   [`impl Default for std::collections::btree_map::RangeMut`](https://doc.rust-lang.org/nightly/std/collections/btree_map/struct.RangeMut.html#impl-Default-for-RangeMut%3C'\_,+K,+V%3E)
-   [`impl Default for std::collections::btree_map::ValuesMut`](https://doc.rust-lang.org/nightly/std/collections/btree_map/struct.ValuesMut.html#impl-Default-for-ValuesMut%3C'\_,+K,+V%3E)
-   [`impl Default for std::collections::vec_deque::Iter`](https://doc.rust-lang.org/nightly/std/collections/vec_deque/struct.Iter.html#impl-Default-for-Iter%3C'\_,+T%3E)
-   [`impl Default for std::collections::vec_deque::IterMut`](https://doc.rust-lang.org/nightly/std/collections/vec_deque/struct.IterMut.html#impl-Default-for-IterMut%3C'\_,+T%3E)
-   [`Rc<T>::new_uninit`](https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html#method.new_uninit)
-   [`Rc<T>::assume_init`](https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html#method.assume_init)
-   [`Rc<[T]>::new_uninit_slice`](https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html#method.new_uninit_slice)
-   [`Rc<[MaybeUninit<T>]>::assume_init`](https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html#method.assume_init-1)
-   [`Arc<T>::new_uninit`](https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.new_uninit)
-   [`Arc<T>::assume_init`](https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.assume_init)
-   [`Arc<[T]>::new_uninit_slice`](https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.new_uninit_slice)
-   [`Arc<[MaybeUninit<T>]>::assume_init`](https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.assume_init-1)
-   [`Box<T>::new_uninit`](https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#method.new_uninit)
-   [`Box<T>::assume_init`](https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#method.assume_init)
-   [`Box<[T]>::new_uninit_slice`](https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#method.new_uninit_slice)
-   [`Box<[MaybeUninit<T>]>::assume_init`](https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#method.assume_init-1)
-   [`core::arch::x86_64::_bextri_u64`](https://doc.rust-lang.org/stable/core/arch/x86\_64/fn.\_bextri_u64.html)
-   [`core::arch::x86_64::_bextri_u32`](https://doc.rust-lang.org/stable/core/arch/x86\_64/fn.\_bextri_u32.html)
-   [`core::arch::x86::_mm_broadcastsi128_si256`](https://doc.rust-lang.org/stable/core/arch/x86/fn.\_mm_broadcastsi128\_si256.html)
-   [`core::arch::x86::_mm256_stream_load_si256`](https://doc.rust-lang.org/stable/core/arch/x86/fn.\_mm256\_stream_load_si256.html)
-   [`core::arch::x86::_tzcnt_u16`](https://doc.rust-lang.org/stable/core/arch/x86/fn.\_tzcnt_u16.html)
-   [`core::arch::x86::_mm_extracti_si64`](https://doc.rust-lang.org/stable/core/arch/x86/fn.\_mm_extracti_si64.html)
-   [`core::arch::x86::_mm_inserti_si64`](https://doc.rust-lang.org/stable/core/arch/x86/fn.\_mm_inserti_si64.html)
-   [`core::arch::x86::_mm_storeu_si16`](https://doc.rust-lang.org/stable/core/arch/x86/fn.\_mm_storeu_si16.html)
-   [`core::arch::x86::_mm_storeu_si32`](https://doc.rust-lang.org/stable/core/arch/x86/fn.\_mm_storeu_si32.html)
-   [`core::arch::x86::_mm_storeu_si64`](https://doc.rust-lang.org/stable/core/arch/x86/fn.\_mm_storeu_si64.html)
-   [`core::arch::x86::_mm_loadu_si16`](https://doc.rust-lang.org/stable/core/arch/x86/fn.\_mm_loadu_si16.html)
-   [`core::arch::x86::_mm_loadu_si32`](https://doc.rust-lang.org/stable/core/arch/x86/fn.\_mm_loadu_si32.html)
-   [`core::arch::wasm32::u8x16_relaxed_swizzle`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u8x16\_relaxed_swizzle.html)
-   [`core::arch::wasm32::i8x16_relaxed_swizzle`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i8x16\_relaxed_swizzle.html)
-   [`core::arch::wasm32::i32x4_relaxed_trunc_f32x4`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i32x4\_relaxed_trunc_f32x4.html)
-   [`core::arch::wasm32::u32x4_relaxed_trunc_f32x4`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u32x4\_relaxed_trunc_f32x4.html)
-   [`core::arch::wasm32::i32x4_relaxed_trunc_f64x2_zero`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i32x4\_relaxed_trunc_f64x2\_zero.html)
-   [`core::arch::wasm32::u32x4_relaxed_trunc_f64x2_zero`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u32x4\_relaxed_trunc_f64x2\_zero.html)
-   [`core::arch::wasm32::f32x4_relaxed_madd`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f32x4\_relaxed_madd.html)
-   [`core::arch::wasm32::f32x4_relaxed_nmadd`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f32x4\_relaxed_nmadd.html)
-   [`core::arch::wasm32::f64x2_relaxed_madd`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f64x2\_relaxed_madd.html)
-   [`core::arch::wasm32::f64x2_relaxed_nmadd`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f64x2\_relaxed_nmadd.html)
-   [`core::arch::wasm32::i8x16_relaxed_laneselect`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i8x16\_relaxed_laneselect.html)
-   [`core::arch::wasm32::u8x16_relaxed_laneselect`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u8x16\_relaxed_laneselect.html)
-   [`core::arch::wasm32::i16x8_relaxed_laneselect`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i16x8\_relaxed_laneselect.html)
-   [`core::arch::wasm32::u16x8_relaxed_laneselect`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u16x8\_relaxed_laneselect.html)
-   [`core::arch::wasm32::i32x4_relaxed_laneselect`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i32x4\_relaxed_laneselect.html)
-   [`core::arch::wasm32::u32x4_relaxed_laneselect`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u32x4\_relaxed_laneselect.html)
-   [`core::arch::wasm32::i64x2_relaxed_laneselect`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i64x2\_relaxed_laneselect.html)
-   [`core::arch::wasm32::u64x2_relaxed_laneselect`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u64x2\_relaxed_laneselect.html)
-   [`core::arch::wasm32::f32x4_relaxed_min`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f32x4\_relaxed_min.html)
-   [`core::arch::wasm32::f32x4_relaxed_max`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f32x4\_relaxed_max.html)
-   [`core::arch::wasm32::f64x2_relaxed_min`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f64x2\_relaxed_min.html)
-   [`core::arch::wasm32::f64x2_relaxed_max`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f64x2\_relaxed_max.html)
-   [`core::arch::wasm32::i16x8_relaxed_q15mulr`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i16x8\_relaxed_q15mulr.html)
-   [`core::arch::wasm32::u16x8_relaxed_q15mulr`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u16x8\_relaxed_q15mulr.html)
-   [`core::arch::wasm32::i16x8_relaxed_dot_i8x16_i7x16`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i16x8\_relaxed_dot_i8x16\_i7x16.html)
-   [`core::arch::wasm32::u16x8_relaxed_dot_i8x16_i7x16`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u16x8\_relaxed_dot_i8x16\_i7x16.html)
-   [`core::arch::wasm32::i32x4_relaxed_dot_i8x16_i7x16_add`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i32x4\_relaxed_dot_i8x16\_i7x16\_add.html)
-   [`core::arch::wasm32::u32x4_relaxed_dot_i8x16_i7x16_add`](https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u32x4\_relaxed_dot_i8x16\_i7x16\_add.html)

These APIs are now stable in const contexts:

-   [`std::task::Waker::from_raw`](https://doc.rust-lang.org/nightly/std/task/struct.Waker.html#method.from_raw)
-   [`std::task::Context::from_waker`](https://doc.rust-lang.org/nightly/std/task/struct.Context.html#method.from_waker)
-   [`std::task::Context::waker`](https://doc.rust-lang.org/nightly/std/task/struct.Context.html#method.waker)
-   [`$integer::from_str_radix`](https://doc.rust-lang.org/nightly/std/primitive.u32.html#method.from_str_radix)
-   [`std::num::ParseIntError::kind`](https://doc.rust-lang.org/nightly/std/num/struct.ParseIntError.html#method.kind)

<a id="1.82.0-Cargo"></a>

## Cargo

-   [feat: Add `info` cargo subcommand](rust-lang/cargo#14141)

<a id="1.82.0-Compatibility-Notes"></a>

## Compatibility Notes

-   We now [disallow setting some built-in cfgs via the command-line](rust-lang/rust#126158) with the newly added [`explicit_builtin_cfgs_in_flags`](https://doc.rust-lang.org/rustc/lints/listing/deny-by-default.html#explicit-builtin-cfgs-in-flags) lint in order to prevent incoherent state, eg. `windows` cfg active but target is Linux based. The appropriate [`rustc` flag](https://doc.rust-lang.org/rustc/command-line-arguments.html) should be used instead.
-   The standard library has a new implementation of `binary_search` which is significantly improves performance ([#&#8203;128254](rust-lang/rust#128254)). However when a sorted slice has multiple values which compare equal, the new implementation may select a different value among the equal ones than the old implementation.
-   [illumos/Solaris now sets `MSG_NOSIGNAL` when writing to sockets](rust-lang/rust#128259). This avoids killing the process with SIGPIPE when writing to a closed socket, which matches the existing behavior on other UNIX targets.
-   [Removes a problematic hack that always passed the --whole-archive linker flag for tests, which may cause linker errors for code accidentally relying on it.](rust-lang/rust#128400)
-   The WebAssembly target features `multivalue` and `reference-types` are now
    both enabled by default. These two features both have subtle changes implied
    for generated WebAssembly binaries. For the `multivalue` feature, WebAssembly
    target support has changed when upgrading to LLVM 19. Support for generating
    functions with multiple returns no longer works and
    `-Ctarget-feature=+multivalue` has a different meaning than it did in LLVM 18
    and prior. There is no longer any supported means to generate a module that has
    a function with multiple returns in WebAssembly from Rust source code. For the
    `reference-types` feature the encoding of immediates in the `call_indirect`, a
    commonly used instruction by the WebAssembly backend, has changed. Validators
    and parsers which don't understand the `reference-types` proposal will no
    longer accept modules produced by LLVM due to this change in encoding of
    immediates. Additionally these features being enabled are encoded in the
    `target_features` custom section and may affect downstream tooling such as
    `wasm-opt` consuming the module. Generating a WebAssembly module that disables
    default features requires `-Zbuild-std` support from Cargo and more information
    can be found at
    [rust-lang/rust#128511](rust-lang/rust#128511).
-   [Rust now raises unsafety errors for union patterns in parameter-position](rust-lang/rust#130531)

<a id="1.82.0-Internal-Changes"></a>

## Internal Changes

These changes do not affect any public interfaces of Rust, but they represent
significant improvements to the performance or internals of rustc and related
tools.

-   [Update to LLVM 19](rust-lang/rust#127513)

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this MR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box

---

This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40NDAuNyIsInVwZGF0ZWRJblZlciI6IjM3LjQ0MC43IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
qryxip added a commit to qryxip/voicevox_core that referenced this pull request Oct 19, 2024
Rustを1.82.0に上げてClippyの対応を行うとともに、次の新機能を利用する。

- `unsafe_attributes` (rust-lang/rust#128771)
- `raw_ref_op` (rust-lang/rust#127679)
qryxip added a commit to qryxip/voicevox_core that referenced this pull request Oct 19, 2024
Rustを1.82.0に上げてClippyの対応を行うとともに、次の新機能を利用する。

- `unsafe_attributes` (rust-lang/rust#128771)
- `raw_ref_op` (rust-lang/rust#127679)
qryxip added a commit to qryxip/voicevox_core that referenced this pull request Oct 19, 2024
Rustを1.82.0に上げてClippyの対応を行うとともに、次の新機能を利用する。

- `unsafe_attributes` (rust-lang/rust#128771)
- `raw_ref_op` (rust-lang/rust#127679)
qryxip added a commit to qryxip/voicevox_core that referenced this pull request Oct 19, 2024
Rustを1.82.0に上げてClippyの対応を行うとともに、次の新機能を利用する。

- `unsafe_attributes` (rust-lang/rust#128771)
- `raw_ref_op` (rust-lang/rust#127679)
qryxip added a commit to VOICEVOX/voicevox_core that referenced this pull request Oct 20, 2024
Rustを1.82.0に上げてClippyの対応を行うとともに、次の新機能を利用する。

- `unsafe_attributes` (rust-lang/rust#128771)
- `raw_ref_op` (rust-lang/rust#127679)
wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request Oct 27, 2024
Pkgsrc changes:
 * Adapt patches, apply to new vendored crates where needed.
 * Back-port rust pull request 130110, "make dist vendoring configurable"
 * Disable "dist vendoring", otherwise cargo would try to access
   the network during the build phase.

Upstream changes:

Version 1.82.0 (2024-10-17)
==========================

Language
--------
- [Don't make statement nonterminals match pattern nonterminals]
  (rust-lang/rust#120221)
- [Patterns matching empty types can now be omitted in common cases]
  (rust-lang/rust#122792)
- [Enforce supertrait outlives obligations when using trait impls]
  (rust-lang/rust#124336)
- [`addr_of(_mut)!` macros and the newly stabilized `&raw (const|mut)`
  are now safe to use with all static items]
  (rust-lang/rust#125834)
- [size_of_val_raw: for length 0 this is safe to call]
  (rust-lang/rust#126152)
- [Reorder trait bound modifiers *after* `for<...>` binder in trait bounds]
  (rust-lang/rust#127054)
- [Stabilize opaque type precise capturing (RFC 3617)]
  (rust-lang/rust#127672)
- [Stabilize `&raw const` and `&raw mut` operators (RFC 2582)]
  (rust-lang/rust#127679)
- [Stabilize unsafe extern blocks (RFC 3484)]
  (rust-lang/rust#127921)
- [Stabilize nested field access in `offset_of!`]
  (rust-lang/rust#128284)
- [Do not require `T` to be live when dropping `[T; 0]`]
  (rust-lang/rust#128438)
- [Stabilize `const` operands in inline assembly]
  (rust-lang/rust#128570)
- [Stabilize floating-point arithmetic in `const fn`]
  (rust-lang/rust#128596)
- [Stabilize explicit opt-in to unsafe attributes]
  (rust-lang/rust#128771)
- [Document NaN bit patterns guarantees]
  (rust-lang/rust#129559)

Compiler
--------
- [Promote riscv64gc-unknown-linux-musl to tier 2]
  (rust-lang/rust#122049)
- [Promote Mac Catalyst targets `aarch64-apple-ios-macabi` and
  `x86_64-apple-ios-macabi` to Tier 2, and ship them with rustup]
  (rust-lang/rust#126450)
- [Add tier 3 NuttX based targets for RISC-V and ARM]
  (rust-lang/rust#127755)
- [Add tier 3 powerpc-unknown-linux-muslspe target]
  (rust-lang/rust#127905)
- [Improved diagnostics to explain why a pattern is unreachable]
  (rust-lang/rust#128034)
- [The compiler now triggers the unreachable code warning properly
  for async functions that don't return/are `-> !`]
  (rust-lang/rust#128443)
- [Promote `aarch64-apple-darwin` to Tier 1]
  (rust-lang/rust#128592)
- [Add Trusty OS target `aarch64-unknown-trusty` and `armv7-unknown-trusty`
  as tier 3 targets] (rust-lang/rust#129490)
- [Promote `wasm32-wasip2` to Tier 2.]
  (rust-lang/rust#126967)

Libraries
---------
- [Generalize `{Rc,Arc}::make_mut()` to `Path`, `OsStr`, and `CStr`.]
  (rust-lang/rust#126877)

Stabilized APIs
---------------
- [`std::thread::Builder::spawn_unchecked`]
  (https://doc.rust-lang.org/stable/std/thread/struct.Builder.html#method.spawn_unchecked)
- [`std::str::CharIndices::offset`]
  (https://doc.rust-lang.org/nightly/std/str/struct.CharIndices.html#method.offset)
- [`std::option::Option::is_none_or`]
  (https://doc.rust-lang.org/nightly/std/option/enum.Option.html#method.is_none_or)
- [`[T]::is_sorted`]
  (https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.is_sorted)
- [`[T]::is_sorted_by`]
  (https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.is_sorted_by)
- [`[T]::is_sorted_by_key`]
  (https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.is_sorted_by_key)
- [`Iterator::is_sorted`]
  (https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.is_sorted)
- [`Iterator::is_sorted_by`]
  (https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.is_sorted_by)
- [`Iterator::is_sorted_by_key`]
  (https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.is_sorted_by_key)
- [`std::future::Ready::into_inner`]
  (https://doc.rust-lang.org/nightly/std/future/struct.Ready.html#method.into_inner)
- [`std::iter::repeat_n`]
  (https://doc.rust-lang.org/nightly/std/iter/fn.repeat_n.html)
- [`impl<T: Clone> DoubleEndedIterator for Take<Repeat<T>>`]
  (https://doc.rust-lang.org/nightly/std/iter/struct.Take.html#impl-DoubleEndedIterator-for-Take%3CRepeat%3CT%3E%3E)
- [`impl<T: Clone> ExactSizeIterator for Take<Repeat<T>>`]
  (https://doc.rust-lang.org/nightly/std/iter/struct.Take.html#impl-ExactSizeIterator-for-Take%3CRepeat%3CT%3E%3E)
- [`impl<T: Clone> ExactSizeIterator for Take<RepeatWith<T>>`]
  (https://doc.rust-lang.org/nightly/std/iter/struct.Take.html#impl-ExactSizeIterator-for-Take%3CRepeatWith%3CF%3E%3E)
- [`impl Default for std::collections::binary_heap::Iter`]
  (https://doc.rust-lang.org/nightly/std/collections/binary_heap/struct.Iter.html#impl-Default-for-Iter%3C'_,+T%3E)
- [`impl Default for std::collections::btree_map::RangeMut`]
  (https://doc.rust-lang.org/nightly/std/collections/btree_map/struct.RangeMut.html#impl-Default-for-RangeMut%3C'_,+K,+V%3E)
- [`impl Default for std::collections::btree_map::ValuesMut`]
  (https://doc.rust-lang.org/nightly/std/collections/btree_map/struct.ValuesMut.html#impl-Default-for-ValuesMut%3C'_,+K,+V%3E)
- [`impl Default for std::collections::vec_deque::Iter`]
  (https://doc.rust-lang.org/nightly/std/collections/vec_deque/struct.Iter.html#impl-Default-for-Iter%3C'_,+T%3E)
- [`impl Default for std::collections::vec_deque::IterMut`]
  (https://doc.rust-lang.org/nightly/std/collections/vec_deque/struct.IterMut.html#impl-Default-for-IterMut%3C'_,+T%3E)
- [`Rc<T>::new_uninit`]
  (https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html#method.new_uninit)
- [`Rc<T>::assume_init`]
  (https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html#method.assume_init)
- [`Rc<[T]>::new_uninit_slice`]
  (https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html#method.new_uninit_slice)
- [`Rc<[MaybeUninit<T>]>::assume_init`]
  (https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html#method.assume_init-1)
- [`Arc<T>::new_uninit`]
  (https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.new_uninit)
- [`Arc<T>::assume_init`]
  (https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.assume_init)
- [`Arc<[T]>::new_uninit_slice`]
  (https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.new_uninit_slice)
- [`Arc<[MaybeUninit<T>]>::assume_init`]
  (https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.assume_init-1)
- [`Box<T>::new_uninit`]
  (https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#method.new_uninit)
- [`Box<T>::assume_init`]
  (https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#method.assume_init)
- [`Box<[T]>::new_uninit_slice`]
  (https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#method.new_uninit_slice)
- [`Box<[MaybeUninit<T>]>::assume_init`]
  (https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#method.assume_init-1)
- [`core::arch::x86_64::_bextri_u64`]
  (https://doc.rust-lang.org/stable/core/arch/x86_64/fn._bextri_u64.html)
- [`core::arch::x86_64::_bextri_u32`]
  (https://doc.rust-lang.org/stable/core/arch/x86_64/fn._bextri_u32.html)
- [`core::arch::x86::_mm_broadcastsi128_si256`]
  (https://doc.rust-lang.org/stable/core/arch/x86/fn._mm_broadcastsi128_si256.html)
- [`core::arch::x86::_mm256_stream_load_si256`]
  (https://doc.rust-lang.org/stable/core/arch/x86/fn._mm256_stream_load_si256.html)
- [`core::arch::x86::_tzcnt_u16`]
  (https://doc.rust-lang.org/stable/core/arch/x86/fn._tzcnt_u16.html)
- [`core::arch::x86::_mm_extracti_si64`]
  (https://doc.rust-lang.org/stable/core/arch/x86/fn._mm_extracti_si64.html)
- [`core::arch::x86::_mm_inserti_si64`]
  (https://doc.rust-lang.org/stable/core/arch/x86/fn._mm_inserti_si64.html)
- [`core::arch::x86::_mm_storeu_si16`]
  (https://doc.rust-lang.org/stable/core/arch/x86/fn._mm_storeu_si16.html)
- [`core::arch::x86::_mm_storeu_si32`]
  (https://doc.rust-lang.org/stable/core/arch/x86/fn._mm_storeu_si32.html)
- [`core::arch::x86::_mm_storeu_si64`]
  (https://doc.rust-lang.org/stable/core/arch/x86/fn._mm_storeu_si64.html)
- [`core::arch::x86::_mm_loadu_si16`]
  (https://doc.rust-lang.org/stable/core/arch/x86/fn._mm_loadu_si16.html)
- [`core::arch::x86::_mm_loadu_si32`]
  (https://doc.rust-lang.org/stable/core/arch/x86/fn._mm_loadu_si32.html)
- [`core::arch::wasm32::u8x16_relaxed_swizzle`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u8x16_relaxed_swizzle.html)
- [`core::arch::wasm32::i8x16_relaxed_swizzle`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i8x16_relaxed_swizzle.html)
- [`core::arch::wasm32::i32x4_relaxed_trunc_f32x4`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i32x4_relaxed_trunc_f32x4.html)
- [`core::arch::wasm32::u32x4_relaxed_trunc_f32x4`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u32x4_relaxed_trunc_f32x4.html)
- [`core::arch::wasm32::i32x4_relaxed_trunc_f64x2_zero`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i32x4_relaxed_trunc_f64x2_zero.html)
- [`core::arch::wasm32::u32x4_relaxed_trunc_f64x2_zero`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u32x4_relaxed_trunc_f64x2_zero.html)
- [`core::arch::wasm32::f32x4_relaxed_madd`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f32x4_relaxed_madd.html)
- [`core::arch::wasm32::f32x4_relaxed_nmadd`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f32x4_relaxed_nmadd.html)
- [`core::arch::wasm32::f64x2_relaxed_madd`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f64x2_relaxed_madd.html)
- [`core::arch::wasm32::f64x2_relaxed_nmadd`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f64x2_relaxed_nmadd.html)
- [`core::arch::wasm32::i8x16_relaxed_laneselect`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i8x16_relaxed_laneselect.html)
- [`core::arch::wasm32::u8x16_relaxed_laneselect`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u8x16_relaxed_laneselect.html)
- [`core::arch::wasm32::i16x8_relaxed_laneselect`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i16x8_relaxed_laneselect.html)
- [`core::arch::wasm32::u16x8_relaxed_laneselect`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u16x8_relaxed_laneselect.html)
- [`core::arch::wasm32::i32x4_relaxed_laneselect`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i32x4_relaxed_laneselect.html)
- [`core::arch::wasm32::u32x4_relaxed_laneselect`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u32x4_relaxed_laneselect.html)
- [`core::arch::wasm32::i64x2_relaxed_laneselect`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i64x2_relaxed_laneselect.html)
- [`core::arch::wasm32::u64x2_relaxed_laneselect`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u64x2_relaxed_laneselect.html)
- [`core::arch::wasm32::f32x4_relaxed_min`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f32x4_relaxed_min.html)
- [`core::arch::wasm32::f32x4_relaxed_max`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f32x4_relaxed_max.html)
- [`core::arch::wasm32::f64x2_relaxed_min`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f64x2_relaxed_min.html)
- [`core::arch::wasm32::f64x2_relaxed_max`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.f64x2_relaxed_max.html)
- [`core::arch::wasm32::i16x8_relaxed_q15mulr`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i16x8_relaxed_q15mulr.html)
- [`core::arch::wasm32::u16x8_relaxed_q15mulr`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u16x8_relaxed_q15mulr.html)
- [`core::arch::wasm32::i16x8_relaxed_dot_i8x16_i7x16`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i16x8_relaxed_dot_i8x16_i7x16.html)
- [`core::arch::wasm32::u16x8_relaxed_dot_i8x16_i7x16`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u16x8_relaxed_dot_i8x16_i7x16.html)
- [`core::arch::wasm32::i32x4_relaxed_dot_i8x16_i7x16_add`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.i32x4_relaxed_dot_i8x16_i7x16_add.html)
- [`core::arch::wasm32::u32x4_relaxed_dot_i8x16_i7x16_add`]
  (https://doc.rust-lang.org/nightly/core/arch/wasm32/fn.u32x4_relaxed_dot_i8x16_i7x16_add.html)

These APIs are now stable in const contexts:

- [`std::task::Waker::from_raw`]
  (https://doc.rust-lang.org/nightly/std/task/struct.Waker.html#method.from_raw)
- [`std::task::Waker::waker`]
  (https://doc.rust-lang.org/nightly/std/task/struct.Waker.html#method.from_raw)
- [`std::task::Context::from_waker`]
  (https://doc.rust-lang.org/nightly/std/task/struct.Context.html#method.from_waker)
- [`std::task::Context::waker`]
  (https://doc.rust-lang.org/nightly/std/task/struct.Context.html#method.waker)
- [`$integer::from_str_radix`]
  (https://doc.rust-lang.org/nightly/std/primitive.u32.html#method.from_str_radix)
- [`std::num::ParseIntError::kind`]
  (https://doc.rust-lang.org/nightly/std/num/struct.ParseIntError.html#method.kind)

Cargo
-----
- [feat: Add `info` cargo subcommand]
  (rust-lang/cargo#14141)

Compatibility Notes
-------------------
 - We now [disallow setting some built-in cfgs via the
   command-line](rust-lang/rust#126158) with
   the newly added
   [`explicit_builtin_cfgs_in_flags`]
   (https://doc.rust-lang.org/rustc/lints/listing/deny-by-default.html#explicit-builtin-cfgs-in-flags)
   lint in order to prevent incoherent state, eg. `windows` cfg active
   but target is Linux based. The appropriate [`rustc` flag]
   (https://doc.rust-lang.org/rustc/command-line-arguments.html)
   should be used instead.

- The standard library has a new implementation of `binary_search`
  which is significantly improves performance
  ([#128254](rust-lang/rust#128254)). However
  when a sorted slice has multiple values which compare equal, the
  new implementation may select a different value among the equal
  ones than the old implementation.

- [illumos/Solaris now sets `MSG_NOSIGNAL` when writing to
  sockets](rust-lang/rust#128259). This avoids
  killing the process with SIGPIPE when writing to a closed socket,
  which matches the existing behavior on other UNIX targets.

- [Removes a problematic hack that always passed the --whole-archive
  linker flag for tests, which may cause linker errors for code
  accidentally relying on it.]
  (rust-lang/rust#128400)

- The WebAssembly target features `multivalue` and `reference-types`
  are now both enabled by default. These two features both have
  subtle changes implied for generated WebAssembly binaries. For
  the `multivalue` feature, WebAssembly target support has changed
  when upgrading to LLVM 19. Support for generating functions with
  multiple returns no longer works and `-Ctarget-feature=+multivalue`
  has a different meaning than it did in LLVM 18 and prior. There
  is no longer any supported means to generate a module that has
  a function with multiple returns in WebAssembly from Rust source
  code. For the `reference-types` feature the encoding of immediates
  in the `call_indirect`, a commonly used instruction by the
  WebAssembly backend, has changed. Validators and parsers which
  don't understand the `reference-types` proposal will no longer
  accept modules produced by LLVM due to this change in encoding
  of immediates. Additionally these features being enabled are
  encoded in the `target_features` custom section and may affect
  downstream tooling such as `wasm-opt` consuming the module.
  Generating a WebAssembly module that disables default features
  requires `-Zbuild-std` support from Cargo and more information
  can be found at
  [rust-lang/rust#128511](rust-lang/rust#128511).
- [Rust now raises unsafety errors for union patterns in parameter-position]
  (rust-lang/rust#130531)

Internal Changes
----------------

These changes do not affect any public interfaces of Rust, but they
represent significant improvements to the performance or internals
of rustc and related tools.

- [Update to LLVM 19]
  (rust-lang/rust#127513)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. F-raw_ref_op `#![feature(raw_ref_op)]` finished-final-comment-period The final comment period is finished for this PR / Issue. PG-exploit-mitigations Project group: Exploit mitigations relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-opsem Relevant to the opsem team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tracking issue for RFC 2582, &raw [mut | const] $place (raw_ref_op)